Naming Convention for Metrics and Metric Recurrence
We use the name of the metric in many places, and a naming convention helps keep a large library of metrics organized. Metrics have names in the form fin_TCO_perTotalRevenue_percent_monthly. The text below describes this convention.
Business-functional areas: Use a prefix to denote the business functional area responsible for producing the metric. Note: Some of these prefixes were named according to the former names of the domain or application.
Business Functional Area | Prefix |
---|---|
Health & Safety | ehs_ |
Environment | env_ |
Finance | fin_ |
Facility Management | fm_ |
Leases | leas_ |
Moves | move_ |
Space Management - Occupancy | occ_ |
Maintenance | ops_ |
Projects | proj_ |
Real Property | repm_ |
Sustainability & Risk | risk_ |
Security | secur_ |
Space | spac_ |
Metric Code. Name the metric per the overall total or count (e.g. RealEstateOpEx).
Related Metric Codes. Use a dash ("-") and a sub-category to name closely-related metrics, such as those that differ only by a condition as to what they include (e.g. RealEstateOpEx-Leased vs. RealEstateOpEx-Owned).
Ratio Metrics. Use an underscore ("_") to name ratio metrics in the same form as the root metric they prorate, and use parentheses to title them. Consider Total-Cost of Occupancy. The root metric would be titled "Total Cost of Occupancy (TCO)" and named "TCO". The ratio metric that prorate this value over gross area would be titled "TCO (per Gross Area)" and named TCO_perGrossArea.
Units. Use generic unit names in the titles (e.g. "Gross Area", "per Gross Area") rather than metric or imperial names (e.g. "per GSF"). You can depend on the Display Units of the actual values (e.g. $45/GSF, €12/GSM, or 12.2 mt) to express the units.
Percent Suffix. Only use a suffix (e.g. _percent) for values that are not clearly percentages (e.g. to distinguish "Teleworker" from "Teleworkers_percent").
Recurrence Period Suffix. Add a suffix to denote the collection recurrence:
Recurrence Period Suffix |
---|
_annually |
_quarterly |
_monthly |
_weekly |
Metric Recurrence
There are several points to make about defining metrics and their recurrence:
Multiple Metrics. There is no conflict in having two separate metrics on the same value with different recurrence periods. For instance, you can collect Total Work Order costs both monthly (for month-to-month operations management) and yearly (for comparing operations cost to the large budget).
Metrics on Inventory Tables. For inventory metrics, the recurrence denotes only how often the value is calculated. For instance, consider the number of Buildings (repm_Buildings_monthly
) or the Rentable Area (spac_RentableArea_monthly
) for all buildings. These measure the total quantity of buildings or total rentable area every month. Even if these metrics fired every year or every week, they would still represent the total quantity of buildings or the total rentable area.
Metrics on Transaction Tables. For metrics on transaction tables, the recurrence denotes both how often the value is calculated and the time period that the metric considers. Consider "Work Requests (by Month)" (ops_WorkRequested_monthly
). The metric recurrence is "monthly" meaning that the metric rule calculates this value each month on the last day of the month. However this metric only considers transactions that occurred over that month. If this metric had an annual recurrence "Work Requests (by Year)" it would be calculated on the last day of the year and would consider work requests over the entire year.